Re: [Gimp-user] Problem importing raw Minolta and Sony files



* Jeffery Small <jeff cjsa com> [04-05-14 16:15]:
Partha Bagchi <partha1b gmail com> writes:

Can you provide an example image to confirm this?

Sure.  Let's use the clouds photo since it is a more modern Sony format and
pretty dramatically shows the loss of information.  Point your browser here:

http://smallthoughts.com/photos/misc/GIMP/clouds.arw

and save the image.  This is a 24-Mb image file taken with an Alpha a77
camera.

Thanks for looking at this.  Let me know if I can provide any additional
info.

Regards,
--
Jeff

On Sat, Apr 5, 2014 at 3:11 PM, Jeffery Small <jeff cjsa com> wrote:

Alexander Rabtchevich <alexander v rabtchevich gmx net> writes:

When you look at an imported image in darktable without applying any
corrections, the program shows you the embedded preview, which was made
by the camera itself with all the corrections it (the camera) would made
with the original RAW when converting it to jpg. If you applyin UFRaw a
camera curve, similar to the one in darktable, you will see the similar
result...

It's true that the lion image imported into UFRaw is terribly over exposed,
but that is something that UFRaw is doing to the raw data.  The original
image has proper exposure which was confirmed at the time the picture was
shot as well as the proper exposure from the companion JPEG image (I shoot
RAW+JPG).  In UFRaw the histogram is shoved completely to the right edge
of the spectrum and there is no way to use this tool to fix the picture as
most of the image detail is already lost.  When I open the same file in the
DiMAGE Image Viewer software from Minolta (on a Windows XP machine), the
raw image looks just fine and can be tweaked.

So I have to assume that this is a serious bug in UFRaw and I have reported
it as such.  I'm just confused that I have not heard other people
complaining
about this problem.

Regards,
--
Jeff

_______________________________________________
gimp-user-list mailing list
List address:    gimp-user-list gnome org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list


--001a11c2ef8064e2f704f65119ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Can you provide an example image to confirm this?<div><br>=
</div><div>Thanks,</div><div>Partha</div></div><div class=3D"gmail_extra"><=
br><br><div class=3D"gmail_quote">On Sat, Apr 5, 2014 at 3:11 PM, Jeffery S=
mall <span dir=3D"ltr">&lt;<a href=3D"mailto:jeff cjsa com" target=3D"_blan=
k">jeff cjsa com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Alexander Rabtchevich &lt;<a href=3D"mailto:=
alexander v rabtchevich gmx net">alexander v rabtchevich gmx net</a>&gt; wr=
ites:<br>

<br>
&gt;When you look at an imported image in darktable without applying any<br=

&gt;corrections, the program shows you the embedded preview, which was made=
<br>
&gt;by the camera itself with all the corrections it (the camera) would mad=
e<br>
&gt;with the original RAW when converting it to jpg. If you applyin UFRaw a=
<br>
&gt;camera curve, similar to the one in darktable, you will see the similar=
<br>
&gt;result...<br>
<br>
It&#39;s true that the lion image imported into UFRaw is terribly over expo=
sed,<br>
but that is something that UFRaw is doing to the raw data. =A0The original<=
br>
image has proper exposure which was confirmed at the time the picture was<b=
r>
shot as well as the proper exposure from the companion JPEG image (I shoot<=
br>
RAW+JPG). =A0In UFRaw the histogram is shoved completely to the right edge<=
br>
of the spectrum and there is no way to use this tool to fix the picture as<=
br>
most of the image detail is already lost. =A0When I open the same file in t=
he<br>
DiMAGE Image Viewer software from Minolta (on a Windows XP machine), the<br=

raw image looks just fine and can be tweaked.<br>
<br>
So I have to assume that this is a serious bug in UFRaw and I have reported=
<br>
it as such. =A0I&#39;m just confused that I have not heard other people com=
plaining<br>
about this problem.<br>
<br>
Regards,<br>
--<br>
Jeff<br>
<br>
_______________________________________________<br>
gimp-user-list mailing list<br>
List address: =A0 =A0<a href=3D"mailto:gimp-user-list gnome org">gimp-user-=
list gnome org</a><br>
List membership: <a href=3D"https://mail.gnome.org/mailman/listinfo/gimp-us=
er-list" target=3D"_blank">https://mail.gnome.org/mailman/listinfo/gimp-use=
r-list</a><br>
List archives: =A0 <a href=3D"https://mail.gnome.org/archives/gimp-user-lis=
t" target=3D"_blank">https://mail.gnome.org/archives/gimp-user-list</a><br>
</blockquote></div><br></div>

--001a11c2ef8064e2f704f65119ee--

_______________________________________________
gimp-user-list mailing list
List address:    gimp-user-list gnome org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list

The image provided when opened with auto whitebalance displays a heavy
magenta cast but looks quite average when daylight whitebalance is applied
and even better when exposure is pushed to ~2.0.  Perhaps you have some
screen color correction or other saved parameter skewing ufraw.

I see no particular problem besides a lot of un-needed html bloating a
text function.
-- 
(paka)Patrick Shanahan       Plainfield, Indiana, USA          @ptilopteri
http://en.opensuse.org    openSUSE Community Member    facebook/ptilopteri
http://wahoo.no-ip.org        Photo Album: http://wahoo.no-ip.org/gallery2
Registered Linux User #207535                    @ http://linuxcounter.net


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]