Module: Raw Photo Support
|
chadparry
Joined: 2008-05-30
Posts: 38 |
Posted: Thu, 2011-04-21 09:33
|
|||
|
I've written a new module that adds support for raw photo formats. The attached archive contains a couple patches. Unfortunately, the current handling of resizes and thumbnails is too rigid to be extensible for new image types. The framework assumes that the resizes and thumbnails are both the same image format as the original. Then there is special-case handling for movies, which have to be treated differently. That mechanism leaves no room for extending support to other image types. (The fact that there is special handling for movies in the framework is a red flag). There should be a way to have an original image that is a raw photo, but a derived image that is a JPEG. One of the attached patches shows a (not very good) way in which this could be addressed. But I didn't spend much time on it, because it feels like there needs to be a discussion with the core developers. I'd like to use this thread to develop a strategy for extensibility. Otherwise, gallery3 will always only be able to support JPEG and GIF and PNG images.
|
||||
Posts: 27300
It is on the list of theing to discuss bu the time is ticking and not much time in the day for everything.
Please file a ticket in the tracker: https://sourceforge.net/apps/trac/gallery/newticket so we don't loose track of this.
You might consider creating a fork on the git-hub of G3 so the devs can look at your changes.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 16504
I know it adds more complexity to the code, but... I'm wondering if we need to re-evaluate how we're dealing with photo storage in G3 (of course I'm not the one doing the work on this either...). Right now we strictly have, thumb, resize, full size. If you rotate the image, you rotate and heavily modify and reduce the image quality of the full size image. In G2 we stored and took great pains to keep and not destroy the original photo.
I'm wondering if we could come up with a combination of the two. Maybe an advanced option that's turned off by default (one which 3rd party modules could turn on), but can keep and store original photos without modification, so that users will have the simpler approach that takes up less space and uses less files by default. It would also allow people trying to develop 3rd party add-on support (PDF, TIF, etc) central support for this instead of having to hack-up their own approach where each module that supports different format(s) does something different.... This would also help pave the path for some other issues regarding watermarking, etc.
I know we really wanted to keep things pretty simple, but I also think we are seeing a new dynamic/demographic of users with G3 too. (I really wish I could've made it to GalleryCon this year....) Anyway, just some feedback and opinion. Take it or leave it
____________________________________________
Like Gallery? Like the support? Donate now!
Posts: 27300
The keep original module help with the issue of rotation et cetera.
I have created a ticket for the raw and other file formats. It is on the list we are making but the list is getting long.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 38
Dave, I couldn't find the ticket you opened. I see that #405 is related, though.
Since you don't already have a plan for supporting other image formats, I'll take my favorite idea and run with it. I know it can be done both simply and robustly. Then all you have to do is accept the patch.... You will be willing to accept the patch, right? Or are you saying that there isn't enough time for you to code review outside contributions? Before I put more work in, I just want to confirm that my changes will be committed.
Posts: 27300
https://sourceforge.net/apps/trac/gallery/ticket/1690
Please create a fork on github and provide your code there so the developers can see your changes. Make comments to the ticket above
Cheers
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 38
Thanks, I've commented on the ticket with links to my code.
Posts: 27300
Great job so far.
I think you are missing a semicolon
https://github.com/chadparry/gallery3-contrib/blob/rawphoto/3.0/modules/rawphoto/helpers/rawphoto_installer.php#L26
I was not able to activate the module until I added a semicolon on the end of line 26
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 38
Uggh, that's embarrassing. I had changed that file without testing it. Thanks for the correction.
Posts: 10
Hi ChadParry
I have your RAWphoto running but not sure how it works. When I select add photos I still only see .jpg files, no CR2. Any help would be great.
Thanks
Posts: 38
There is some documentation posted at http://codex.gallery2.org/Gallery3:Modules:rawphoto. The fatal issue is that the Raw Photos module will not work unless more support is built in to the framework itself. Gallery 3.0.1 doesn't properly support RAW photos yet, but hopefully an upcoming version this summer will provide the support. I've been conversing with Bharat for a couple weeks on it. We're making progress.
The only easy way to get RAW photo support is just to wait for a future version of Gallery. But I see you've already been working pretty hard to get this installed, so you probably don't want to wait. Go to the wiki page linked above and follow the installation steps. As the first step describes, you'll have to use Git to download a patch for the Gallery framework, among other things.
Posts: 5
Hi chadparry,
First, thank you for your module and the system for handling new formats, it is really convenient to use. I just would like to point out some issues. I have tried many raw formats to see if everything works fine and there is two bugs in the processing.
You add the entry "image/tiff" to the mime type validator of an item in order to validate the first add of the photo and then you switch the raw image by the jpeg image. The first bug is that some raw formats does not have the "image/tiff" mime type. This is due to the fact that the mime type is detected by the php function get_image_size (called by the function photo::get_metadata_file) and this function does not handle all the format declared handled by your module. So when I add a non supported image, the validation throws an exception.
The second bug is that when the raw image is converted, the mime type of the item is not changed. This can be corrected in item.php by adding at the line 418 the line below or by doing it in the raw photo event.
Posts: 38
Thanks, JohnLoo. Do you have a sample image that I could test with? I've done all my testing on the Canon format, CR2. I think I can fix the first problem just by adding another MIME type to the list of accepted types. I need to examine the image to find out what the detected type is. I wish there standards for these raw formats, but unfortunately I'm afraid we'll have to handle them one at a time as these issues are encountered.
Your fix for the second problem looks good. Can you tell me what the symptoms are when the MIME type is not changed? I didn't realize that field even existed before, so I hadn't noticed when it was wrong.
Posts: 5
I tried every image formats available in this site: http://rawsamples.ch/index_en.php.
. I am sorry I don't have the exact results anymore :/
).
I have also already looked at the result of the function getimagesize and the MIME type "image/tiff" is returned with 8 or 9 formats. One format gives a new mime type and the others just give no MIME type
As far as I know, there are no visible symptoms when the MIME type is not changed but it is better to have the right MIME type indicated. In fact, gallery has not been made to change the image or video related to an item and that is why this is not handled right now. But if some new modules introduce media conversions, this is required (why not video conversion, it could be a pretty good new feature
Oh, just another thing, I have also a weird problem with the flash uploader that I could not explain (even after 2 hours of search) and maybe it also happened to you. When I upload this image for example (format cr2) : http://www.rawsamples.ch/raws/canon/1dm3/RAW_CANON_1DMARK3.CR2, the flash uploader returns an error 2038 but the image is added to Gallery. Maybe this is the conversion time which is too long (the error always happens 35 seconds after the upload request) and maybe there is a timer in the uploader. No big deal but weird
Posts: 38
I have corrected my rawphoto module to keep the MIME type up-to-date. Thanks for the comments, JohnLoo. I still have on my to-do list that I need to investigate those camera images that you showed me.
Posts: 7994
I've merged Chad's changes into the core code -- great work Chad!
---
Problems? Check gallery3/var/logs
file a bug/feature ticket | upgrade to the latest code! | hacking G3? join us on IRC!
Posts: 5
Nice! I was waiting for this feature for a long time now
Thanks!
Since you use the MIME type "image/tiff", it could be interesting to add TIFF and BMP support in your module Chad. The conversion uses only graphics|image magick.
Another suggestion is to copy the EXIF metadata in the output jpeg using exiftool (if installed).
I am still wondering something : why are you using the option "-t 0" with dcraw ? Why not allow the auto rotation based on EXIF data ?
Anyway, thanks a lot! I really like your work
Posts: 38
JohnLoo, I experimented with all the file types from that rawsamples.ch site. I'll have support ready for all of them in version 4 of the module. I had to add the empty string as a supported MIME type. The uploaded image still has to match a limited number of extensions, so it still won't permit just any file format.
I also tested with some very large files. I was able to reproduce the timeout that you saw. The uploader reported that there was an error, but then I saw that the images got imported successfully anyway. I think the failures were misleading. Do you think those are the same as the symptoms you experienced?
The reason I suppressed rotation of the image during raw processing was to allow the regular autorotate module to take care of it. Otherwise the image could get rotated twice. Of course, the EXIF information isn't getting preserved correctly right now, so the rotation is not happening. I'll work on that too for a future version. In the meantime, you could remove the "-t 0" arguments as a workaround.
Posts: 5
Yip, that is the same problem I am having I think so. But no big deal indeed since the file is added as wanted. I hope the flash uploader will be replaced with a JQuery uploader like plupload!
I see your point with the image rotation. I have implemented the exif information transfert in your rawphoto_graphics file. If you are interested, this is the line to add after the execution of the command to convert the image in jpg :
$copy_metadata_cmd = "exiftool -overwrite_original -tagsFromFile '".$input_file."' -all:all '".$output_file."'";
You only need to execute this command as well.
I will keep an eye on your updates and make feedback if I see something weird or if I have suggestions!
Posts: 2
Hey - Firstly thanks for an amazing module! Exactly what we need... and it seems to be working perfectly - for .nef files.
Unfortunately we're having a lot of trouble with cr2's.
I've tried using the icc profiles for the canon but for some reason the photos keep importing as blue silhouettes.
Is there anything I can do about this?
Thanks!!
Posts: 38
@Genloz, I use CR2 images all the time. Can you post the link to your raw photo somewhere? I could try to repro the issue. Also, can you type "dcraw" with no arguments, and check which version you have installed?
Posts: 2
Thanks very much!
it's dcraw v8.19
The photo is here:
www.g-n-l.com/uploaded_images/_MG_2995.zip
Posts: 1
Hi chadparry,
thank you for the module. It seems to be very helpful for lot of us. However somehow I'm now unable to use it with 'server add'. Everything looks fine but it doesn't do anything with my NEF images. If they weren't exist. But when I'm uploading them, it works fine.
Thanks in advance!
Posts: 38
@dsimon, I haven't ever try the "Server add" module, and so I bet that it is incompatible.
One thing that would be useful is if you captured the log files, to see if anything gets written during your failed add. Meanwhile, when I get time, I'll try to reproduce it also.
The Raw Photo module works by listening for an event called "item_created." It's possible that the "Server add" module doesn't fire that event like it should. I did a quick search of the sources for that module and I didn't see the event getting created. So it's possible that a bug will have to be filed against the owner of that module.
Posts: 38
@genloz, I finally got around to investigating your issue. I have dcraw v8.99 installed on my Ubuntu. I tested your photo and it worked fine. Then I installed dcraw v8.19 and tried again. This time, the photo was completely washed out. I didn't investigate the dcraw code any deeper, but I suspect that your camera was not supported until a version of dcraw after 2006. Your version, from 2006, doesn't recognize your camera model correctly, so it is guessing that it is a different Canon with a different raw format. That's why it misinterprets all the colors.
I recommend you install a recent version of dcraw. Use at least v8.99, because I verified that your camera model is detected correctly by that version. The latest version is available at http://www.cybercom.net/~dcoffin/dcraw/.
I would like to add a note to the documentation about this problem. To illustrate the issue, I want to put a correct image and a washed-out image side-by-side. Then I'll have instructions for upgrading dcraw. Would you give me permission to use a thumbnail of your image?
Posts: 38
@dsimon, I reproduced the Server Add bug today. The problem was simpler than I had guessed. In their filesystem traversing code, they only allow 7 different filename extensions. So "*.jpg" files are found but "*.NEF" files are not.
Instead of hard-coding those few extensions, the developers of Server Add should instead use the helper legal_file::get_extensions(). That way, their module will work with all image types, all raw photos, and any other types that are supported in third-party modules.
I don't really have time to follow up with the module developers. Also, after that bug is fixed, there might be other defects related to the "item_created" even that I mentioned earlier. Server Add is a core module, so anyone on the Gallery3 team should be able to work on this. But this should give you some ideas on who you can talk to and how they can address the problem, should you feel inclined to pursue it.
Posts: 16504
I filed a ticket here:
https://sourceforge.net/apps/trac/gallery/ticket/1815
____________________________________________
Like Gallery? Like the support? Donate now!
Posts: 27300
Comments are now permitted for this topic.
Posts: 814
Was testing out the rawphoto module and have a few notes on it:
1) It appears to try and convert images on item_created() for ALL uploaded images
- would it be feasible to check the extension prior to trying to convert (even though I see a fall-through status returned for the 'failed' convert)
2) I noticed that exif info is lost by dcraw conversions...
- in my previous conversion process, I used 'exiftool -TagsFromFile $orig $new' to copy over the exif from the raw to the jpg - exiftool is a unix app, but I'm wondering if the exif module could be tapped into for this
3) Other than #2, this is fantastic!
Edit: I preliminarily patched with a new call to a function for exec'ing the exiftool cmd... works a charm. However, I like your implementation of all the error checking/etc in the module for dcraw, and think that quite a bit more should be done with the exiftool to mimic this. Much more than I'm able to commit to at the moment.
I haven't thought of a fix for #1, but am thinking along the lines of checking (or adding new array) for raw image types and seeing if photo ext is a match, then calling the convert function, or just returning out if not.
Posts: 38
@jnash, that sounds like a great start.
For #2, you could make exiftool detection part of the module settings. Then it would be used if present, or skipped if not present. You could write a function that looks a little like rawphoto_graphics::detect_dcraw(). I think that's pretty much what you are proposing. Like you said, it's much more work once you add all the error handling.
I like the idea of using PHP's exif library instead, but unfortunately it doesn't have the features needed for this.
Another alternative would be to redirect the EXIF queries to the original image. So the image would be displayed from one location, and the EXIF would be retrieved from another. I guess that's just not as good as a solution though, now that I think about it. It would require more complicated code in the exif module. It would only work if the keeporiginal module were activated. And it would not preserve the EXIF data when people download the generated images from the site.
For #1, you probably don't want to mess with all the extensions. There are tons, and they change frequently. Instead, you just have to call "dcraw -i $image". It quickly examines the magic numbers in the image. If it returns a successful exit code, then the file is a raw file. You won't find a better test than that. However, you can imagine that the reason I didn't add that step is because that's the first thing that "dcraw $image" does anyway. If the image is not a raw file, it aborts immediately. So by adding that extra "dcraw -i $image" step, it would make the code more complicated, but the behavior would be indistinguishable.
Posts: 814
Awesome, thanks for the details on #1.
As I started digging in to #2, you're correct, the native exiv support doesn't do what we need.
Since I have it working now, I'll go ahead and begin coding in the error handling as you suggested using rawphoto_graphics::detect_dcraw() I think this will be the most effective way forward. And, since dcraw is a dependency, then no since that exiftool doesn't need to be either, if one desires the functionality.
You don't mind if I proceed on this do you? I'll submit patches instead of creating a new module if that'd be more effective.
Let me know, and thanks again for the great module!
Posts: 814
actually, since it's not a requirement to have the exiftool (required for your module's operation that is) I'm thinking a new raw_exif_copy module may be more effective as to not mess with yours. I could just use an event from your module, I just have to think about it though, cause I need the output_file to exist to grab the exif tags.
Just brainstorming here...
Regardless, I've incorporated rudimentary exiftool_detect() function and disregard the exec if it returns false. I think that's all that's needed. And I placed just one call from your rawphoto_event to call the exifcopy() function from rawphoto_graphics - works a charm!
Let me know your thoughts... I'm not sure if the event trigger will work for a separate module, as you unlink the $output_file
Posts: 38
It sounds to me like you have the right approach. Feel free to request a code review at any point, probably by submitting a pull request to https://github.com/chadparry/gallery3-contrib.
You're certainly welcome to create a separate module. But I think it would be extra unnecessary work. It would be harder for users to have to install two modules for one piece of functionality. Adding an optional dependency to the rawphoto module shouldn't hurt anyone. I'm certainly fine with you modifying that module directly, if that's what you're worried about.
Posts: 814
I'll let you take a look at this patch. See if you want to do anything with it. I appreciate it!
( PS: I'm not really a programmer
Although I sometimes play one on the Net! )
Posts: 3
Is there something special that has to be done so that the original raw image is stored on the server? Currently, I have gallery 3.0.3 installed with the keep original and rawphoto module installed. When I upload a raw photo (a cannon .cr2 file) the picture is converted as expected, but the CR2 file is deleted.
Posts: 38
The keeporiginal module should be sufficient to preserve your photos. Have you checked to see whether the keeporiginal module is working for non-raw photos? Also, what happens if you try to download a raw photo? Does it just offer you the converted jpeg? Depending on your answers, I may need to see a copy of your log to know what is going on.
Posts: 3
The keep original keeps a copy of the original jpg when I rotate an image so I assume it is working like it should. The log doesn't appear to have much of anything in it.
This is all that there is in the log when I uploaded some CR2 files today:
<?php defined('SYSPATH') or die('No direct script access.'); ?>
Posts: 3
After updating gallery to version 3.0.4 the keep original appears to be keeping a copy of the original image now. The one thing that it is doing do is it is renaming the raw file from .CR2 to .jpg. Then when I download the full size, it downloads the rawfile that was renamed to .jpg.
Posts: 38
I'm glad your site is working after the upgrade. I wish I had good news for you about the extension bug. I haven't found any way to fix that without rewriting the keeporiginal module.
I've looked into what it would take to preserve extensions. In the best implementation, a mapping table would have to be maintained in the keeporiginal module, which would track the name of the original file corresponding to each translated file. If no entry existed in the mapping then the name would be assumed to be the same. Extra logic would have to be written to handle the case where two different images had the same original filename. A totally alternate implementation would involve changing the directory structure, so that instead of storing the original at original/myalbum/myimage.jpg, it could be also be found at original/myalbum/myimage.jpg/myimage.cr2. That might be easier to implement than the mapping table, but it also might be confusing that some originals are directories and some are files.
I ended up not addressing the issue myself because I decided not to use keeporiginal in my own Gallery3 installation after all. Someone else will have to take that on eventually. If you want to move this forward, I recommend you start by filing a bug. You can reference the TODO I added to the code here: https://github.com/gallery/gallery3-contrib/blob/master/3.0/modules/keeporiginal/helpers/keeporiginal_event.php#L115.
Posts: 21
Hi,
I am running Gallery 3.0.4 and have installed dcraw 9.06. When uploading a NEF file, an error message appears when the upload is completed: "DSC_0001.NEF: Unable to process this photo"
Looking at the source code, I built up the following command line
This works fine (generating a JPEG that is valid), so I know the tools are functioning properly.
When I look at the var/logs/2012-09-10.log.php file, I see the following error message:
So it appears that the problem is within the uploader, trying to validate the type of file that's being uploaded... and the rawphoto code is not even being called...
Within this forum, there has been mention about mime types, and the error message seems to point towards that, but I don't seem to be able to sort through the code to figure out where the problem is.
Any ideas?
Cheers,
Steve Williams
Posts: 21
Hi,
OK, working my way through the error trace above, I noticed that the path included the "Videos" module.
I de-activated the "Vidoes" module and now magically everything works!
I decided to give a status update rather than deleting my original post in case others encounter the same problem.
Cheers,
Steve Williams
Posts: 21
Hi,
I added the patch to copy over the EXIF information from the ".NEF" to the ".jpg" file and it works perfectly.
HOWEVER... yes, there's always a catch! lol.
How can an event be fired to trigger the EXIF module to pick up the information? When I run "exiftool" on the jpeg in the repository, the EXIF information is present on the file.
When I try to look at the EXIF information from within Gallery3, it comes up blank. Presumably, this is because the EXIF module has already fired... or ...??? I am not sure how all the event driven stuff is hooked together, or rather... how all the modules are supposed to work together.
Any ideas?
Thanks,
Steve Williams
Posts: 21
Hi,
I love replying to myself
The solution is to install the "Module Order" module and make sure the "exif" module runs AFTER the "rawphoto" module.
I have installed the "exif_patch.p" previously posted in the forum so my jpegs also have EXIF information on them.
I installed the autorotate module and I made sure it runs AFTER the rawphoto, and that the the "exif" module runs after the autorotate module and now the EXIF information is present AND ACCURATE... with my photos auto-rotated
Summary:
rawphoto
autorotate
exif
Thanks!
Cheers,
Steve
Posts: 27300
Perhaps the docs need some clarifying?
If you can you can update them yourself or if you can make specific wording suggestions we can do it for you.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 21
Hi,
Earlier this afternoon, I updated the http://codex.gallery2.org/Gallery3:Modules:moduleorder with the following information. I had planned to update jpegtran, exif and rawphoto to include a reference to the "module order" module (with links).
Do you think this is the correct approach?
Posts: 27300
Looks good to me.
Looks like I need to create a http://codex.gallery2.org/Gallery3:Modules:exif page as well unless you want to help with that as well?
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 21
Hi,
I sent you a PM since this is off topic for this thread.
Cheers,
Steve
Posts: 32
Anyone tried this module on the latest G3 and the keeporiginal plugin? For some reason, the .DNG file is stored in /gallery3/var/original but it renames it to .JPG rather than .DNG
Posts: 38
@leonki, I think that's what the behavior has been all along. The original extension is lost, even though the original data file is preserved. To change that would require extensive changes to the keeporiginal module. It could be done, but no one has tried to tackle that job yet. See https://github.com/gallery/gallery3-contrib/blob/master/3.0/modules/keeporiginal/helpers/keeporiginal_event.php#L115 .
Posts: 32
I see now. It's a design limitation. Gallery V3 is made to display RAW images as JPEG images, so it converts the file to the supported format; it copies the original RAW file to the original/ folder. But to keep the original file from being overwritten/destroyed, it is renamed to .jpeg to match the newly created/resized image.
The flaw here is that if more formats are added, it will become difficult to match originals to resized images (imagine if TIFF, CR2, DNG, etc support is added). One can't link files in original back to the album, nor allow users direct access to it, or recover correctly.
The better solution would have been to allow users to see full size JPEG images of RAW images + have link to download the original RAW file (this will allow users such as myself to use Galley + S3 module as a backup repository for all my images)
Posts: 32
I was thinking of how to solve this problem, and wanted to share some ideas before I implemented in my own module/share with others. Here's a scenario of I see this working out:
1) An unsupported file is uploaded to gallery (e.g. ABC.DNG)
2) The file requires modification (convert to JPEG and rotate) - ABC.DNG is copied to original/
3) DCRAW converts ABC.DNG to ABC.jpeg
4) keep original notices the change in extension, and moves original/ABC.DNG to original/ABC.jpeg/ABC.DNG
This will only work on UNIX machines (as directories and files can't have the same name).
What do people think?